home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / e / misc.save / 000059_scottac@nb.sympatico.ca_Fri Jan 19 17:34:22 2007.msg < prev    next >
Internet Message Format  |  2020-01-01  |  6KB

  1. Path: reader2.panix.com!reader1.panix.com!panix!bloom-beacon.mit.edu!news2.wam.umd.edu!elk.ncren.net!newsflash.concordia.ca!News.Dal.Ca!ursa-nb00s0.nbnet.nb.ca!53ab2750!not-for-mail
  2. From: "Scott Caissie" <scottac@nb.sympatico.ca>
  3. Newsgroups: comp.protocols.kermit.misc
  4. References: <xwOhh.34809$cz.516497@ursa-nb00s0.nbnet.nb.ca> <lWShh.32651$tb6.31529@news-wrt-01.rdc-nyc.rr.com> <bF8ih.35271$cz.521966@ursa-nb00s0.nbnet.nb.ca> <4589b00f$0$16922$4c368faf@roadrunner.com> <Gmrih.35742$cz.527501@ursa-nb00s0.nbnet.nb.ca> <458a9baa$0$5926$4c368faf@roadrunner.com> <c3_rh.2668$1x.45361@ursa-nb00s0.nbnet.nb.ca> <45b0c5ad$0$7740$4c368faf@roadrunner.com>
  5. Subject: Re: Macro: Terminal -> Command -> Terminal -> Command?
  6. Lines: 145
  7. X-Priority: 3
  8. X-MSMail-Priority: Normal
  9. X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
  10. X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
  11. X-RFC2646: Format=Flowed; Original
  12. Message-ID: <Nbash.2846$1x.48756@ursa-nb00s0.nbnet.nb.ca>
  13. Date: Fri, 19 Jan 2007 20:51:57 GMT
  14. NNTP-Posting-Host: 156.34.63.9
  15. X-Complaints-To: abuse@aliant.net
  16. X-Trace: ursa-nb00s0.nbnet.nb.ca 1169239917 156.34.63.9 (Fri, 19 Jan 2007 16:51:57 AST)
  17. NNTP-Posting-Date: Fri, 19 Jan 2007 16:51:57 AST
  18. Organization: Aliant Internet
  19. Xref: panix comp.protocols.kermit.misc:15630
  20.  
  21. I expect these commands to send and process the F6 key to the Terminal. The 
  22. Terminal (for me) recognizes this as the Function Key for opening up various 
  23. windows.
  24.  
  25. And the command does in fact work. It sends out the F6 command to be 
  26. processed by the Terminal.... but not when its alone. Its works as expected 
  27. when its proceeded by a non-\Kverb. So I just throw in non-harmful keys in 
  28. front of some of my sequences to guarantee that it will run properly.
  29.  
  30. That sounds very much like a bug.
  31.  
  32.  
  33. "Jeffrey Altman" <jaltman2@nyc.rr.com> wrote in message 
  34. news:45b0c5ad$0$7740$4c368faf@roadrunner.com...
  35. > What are you expecting
  36. >
  37. >   OUTPUT \Kdecf06
  38. >   INPUT <n> \Kdecf06
  39. >
  40. > to do?
  41. >
  42. > Since keyboard escape sequences are not going to be echo'd back to the
  43. > terminal for input processing, it is the equivalent of
  44. >
  45. >   INPUT <n> "some string that is never ever going to come"
  46. >
  47. > You use the INPUT command to wait for the sequence that the host sends
  48. > in response to the sequence you sent with OUTPUT.
  49. >
  50. >
  51. >
  52. > Scott Caissie wrote:
  53. >> Its a pity that it can't be made faster. 1 second is too long when I have 
  54. >> a
  55. >> macro using this numerous times per account.
  56. >>
  57. >> Anyway, I discovered an oddity.
  58. >> Is there a problem with INPUT & Kverbs?
  59. >>
  60. >> On of my macros is trying to use F6 (opens a window for me) but it 
  61. >> doesn't
  62. >> function if it is by itself.
  63. >> I have 3 scenarios listed below.
  64. >>
  65. >> Scenario #1 (my original simple setup)
  66. >> OUTPUT \Kdecf06
  67. >> INPUT 1 \Kdecf06
  68. >> The terminal won't update. In fact it acts like INPUT 0 \Kdecf06. Theres 
  69. >> no
  70. >> actual pause using 1 rather than 0.
  71. >>
  72. >> Scenario #2
  73. >> OUTPUT \Klfarr\Kdecf06
  74. >> INPUT 1 \Klfarr\Kdecf06
  75. >> This also doesn't work....still no actual pause or updating.
  76. >>
  77. >> Scenario #3
  78. >> OUTPUT \8\Kdecf06
  79. >> INPUT 1 \8\Kdecf06
  80. >> This works. I was wondering if Kverbs had complications with this.
  81. >>
  82. >>
  83. >> I had another macro which uses OUTPUT/INPUT very intensely and 
  84. >> occassionally
  85. >> it loses it's place, and I think this might be the reason why. The 
  86. >> terminal
  87. >> doesn't seem to always update when it should. Its going to take me about 
  88. >> an
  89. >> hour to verify if all my statements are being processed correctly, but
  90. >> before I do that, I want to know precisely what I'm looking for.
  91. >>
  92. >>
  93. >>
  94. >>
  95. >> "Jeffrey Altman" <jaltman2@nyc.rr.com> wrote in message
  96. >> news:458a9baa$0$5926$4c368faf@roadrunner.com...
  97. >>> The value is a "timeout" period not a time-you-must-wait-for period.
  98. >>> You could put 1000 there and it wouldn't make a different provided that
  99. >>> the data you are looking for actually arrives.  The value is "how long
  100. >>> should I wait if the pattern I was given does not find a match on the
  101. >>> incoming data stream?"
  102. >>>
  103. >>>
  104. >>>
  105. >>> Scott Caissie wrote:
  106. >>>> That is what my tests today showed.
  107. >>>> With this, I'll have macros that will be running in a loop for about
  108. >>>> 50-200
  109. >>>> times.
  110. >>>> For each, I need only one "INPUT 1" statement at the end to update the
  111. >>>> screen. Up until that point, using a multitude of INPUT 0s works fine. 
  112. >>>> 1
  113. >>>> of
  114. >>>> my projects will need to update the screen twice.
  115. >>>> I ran one today a few times in a loop of 119 times. Worked perfectly.
  116. >>>>
  117. >>>> Though I wish you could allow for fractions of a second. Or an 
  118. >>>> instaneous
  119. >>>> forced update command.
  120. >>>> That would be my wish list for Version 3.0.
  121. >>>>
  122. >>>> But this so far has helped me a lot. Thanks.
  123. >>>>
  124. >>>> - Scott
  125. >>>>
  126. >>>> "Jeffrey Altman" <jaltman2@nyc.rr.com> wrote in message
  127. >>>> news:4589b00f$0$16922$4c368faf@roadrunner.com...
  128. >>>>> Scott Caissie wrote:
  129. >>>>>> I see. I've been testing this out all day, and it works pretty much 
  130. >>>>>> the
  131. >>>>>> way
  132. >>>>>> I was aiming for.  I was never referred to using the INPUT command
  133. >>>>>> before,
  134. >>>>>> and to be honest, I don't understand it 100% yet. I'm basically
  135. >>>>>> mirroring
  136. >>>>>> my
  137. >>>>>> actions.
  138. >>>>>> I do have a question. Is there restrictions about using INPUT 0 
  139. >>>>>> <text>?
  140. >>>>>> This example works fine, but if I use INPUT 0 etc, it won't. I check 
  141. >>>>>> to
  142. >>>>>> see
  143. >>>>>> if it works by using \Fscrnstr(y,x,n) on a large scale.
  144. >>>>>>
  145. >>>>>> SET INPUT TERMINAL ON
  146. >>>>>> set input echo off
  147. >>>>>> clear input-buffer
  148. >>>>>> define vega {
  149. >>>>>> ..LZ_PRO := \Fscrnstr(0,6,8)
  150. >>>>>> OUTPUT \5\5\5\5\5\5\5\5\57\49\13\49\52\13\m(LZ_PRO)\24
  151. >>>>>> INPUT 1 \5\5\5\5\5\5\5\5\57\49\13\49\52\13\m(LZ_PRO)\24
  152. >>>>>> for \%t 1 24 1 {
  153. >>>>>> echo \Fscrnstr(\%t,0,79)
  154. >>>>>> }
  155. >>>>>> }
  156. >>>>> If you use "INPUT 0 <text>" you are not reading any data from the
  157. >>>>> connection.  You must use a timeout greater than 0 in order to process
  158. >>>>> data.
  159. >>>>>
  160. >>>>> Jeffrey Altman
  161. >>>>
  162. >>
  163. >> 
  164.  
  165.